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Abstract 

We discuss denotational semantics of object-oriented languages, using the concept of 
closure widely used in (semi) functional programming to encapsulate side effects. It is 
shown that this denotational framework is adequate to explain classes, instantiation, and 
inheritance in the style of Simula as well as SMALLTALK-80. This framework is then com- 
pared with that of Kamin, in his recent denotational definition of SMALLTALK-80, and the 
implications of the differences between the two approaches are discussed. 


1 Introduction 

Object-oriented languages, such as Smalltalk-80 3 [9], have recently received a lot of atten- 
tion. However, the term “object-oriented” does not seem to have a widely accepted meaning. 
It is sometimes used to refer to the presence of data objects with local state , sometimes to the 
notion of class inheritance, and sometimes to the specific notion of inheritance in Smalltalk 
which involves a kind of “dynamic binding”. The first of these notions, viz., objects with lo- 
cal state, has long been used in the functional programming community to encapsulate “side 
effects” whenever they were necessary [1, 11]. These are sometimes losely referred to as clo- 
sures. A closure is essentially a function or a data structure containing functions with some 
local bindings to values or storage locations. In describing the semantics of object oriented 
kmguages, it seems natural that such a notion of closure should play a central role. 

Smalltalk and other object oriented languages, of course, go much beyond data objects 
with local states. They allow classes to be defined, objects to be created as instances of classes, 
class descriptions to refer to the receiving object in terms of self, and subclasses to be derived 
from superclasses. Whether all these concepts can be explained in terms of closures is an 
interesting question. If so, the denotational semantics of object oriented languages can be 
defined in terms of closures. This paper answers this question in the affirmative and presents 
such a denotational semantics. 

In a recent paper [10], Kamin presented a denotational semantics for Smalltalk-80 using a 
different framework. Here objects are interpreted denotationally as pairs of local environments 
and references to class denotations. The denotations of classes are defined independently of 
the objects that receive messages. The essential objection we raise against this scheme is that 
the semantics is not sufficiently abstract. From the point of view of the user of an object, an 
object simply responds to a set of messages. So, the meaning of am object should simply be 
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an environment binding message names to their methods ( message environments). There is no 
need for the local environment of an object to appear in its denotation. Our presentation of 
the semantics interprets objects precisely as message environments. 

To present the semantics, we discuss a series of small abstract languages. Firstly, Object- 
Talk is a language in which objects can be defined, but no classes. In the second language, 
ClassTalk , classes earn be defined and objects can be created as instances of classes. The third 
language, called InheritTalk, provides subclasses to be defined by inheriting from other classes. 
The bindings of messages used by superclasses ewe not affected by inheritance. The inheri- 
tance of Simula [7] and C++ [18] work in this fashion. Finally, we define a language called 
SmallTalk , which implements inheritance in the style of SMALLTALK-80, by rebinding messages 
in subclasses. It is shown that ClassTalk and InheritTalk are extensions of ObjectTalk, i.e., 
they do not alter the denotations used in earlier languages. But, SmallTalk requires a radical 
restructuring of the denotations. 

In addition, we restate the semantics of Kamin in our notation and formally establish 
their correspondence by showing a homomorphism from Kamin’s semantic domains to ours. 
There does not exist a homomorphism in the other direction, because Kamin’s domains contain 
strictly more information (and hence are less abstract) than ours. 

2 Denotational Framework 

Our style of presentation will be to consider a series of little abstract languages with increasingly 
more expressive power. For obvious reasons, we will not treat a full language, but only those 
portions which sire of interest to object-oriented programming. To set the context, let us first 
give some examples of syntactic constructs: 


x,y € variable 

e 6 expression 


e ::= x 
e ::= valof e 
e ::= x := e 
e ::= let * = e\ in e-i 


Here, we have only two kinds of syntactic objects variable and expression , said three kinds 
of expression constructs. For pedagogical reasons, we use the dereferencing operator valof to 
access the contents of a location. (It allows us to use a single semantic function, rather than 
two separate ones for the l- and r-values of expressions). 

Conventionally, the meaning of an expression [17] is of the type 

env — > state — ► val x state. 

So, an expression valuation r is some (v, o'). The bindings of free variables in e, which 
may be values or locations, are obtained from 77 , and the contents of locations are obtained 
from the state cr. Our semantic domains and a sampler of semantic definitions are given below: 
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e 

variable 


a 

6 

loc 


v, w 

G 

val 

= basieval + loc + • • • 

V 

G 

env 

= variable — ► val 

a 

G 

state 

= loc -* val 


| — ]] : env — ► state — > (t>a/ x state) 


Mw 
Jvalof ej^cr 

lx := 

|let x = e\ in e 2 ^r)cr 


(vx,a) 

let {a, cr') = [eflrjo- 
in a £ loc — » (o-'a, <r'); ? 
let a = T] x 

(u,<Ti) = leaner 

■ in a € loc — ► [a -»»]); ? 

let (v\,<T\) = le^tja 

in 


Let us make a few comments about our notation. The symbol ? denotes an error value. We 
do not elaborate its meaning tiny further. (See [17] for a detailed discussion). Environments 
and states are finite functions, and we often need to update them (like in the semantics of 
assignment above). The notation 

/[*-►«] 

means a copy of the function / that maps x to v, leaving everything else unchanged. We also 
use the notation 

f[xi-+Vx,...,X k ->V k ] 

when we need to update the mapping of several values simultaneously. A third notational 
device is 

/;/' 

which means updating of / with all the bindings of /' (note: f should be a finite mapping). 
The symbol tj ± denotes the empty environment and <r± deontes the empty state. 

The notion of closure arises from the fact that expressions may have free (nonlocal) variables. 
The type env — *• state -* ( val x state) shows that an expression valuation depends on an 
environment and a state. Given both, the value of the expression is fixed. Now, consider a 
procedure valued expression with free variables, e.g., 

let /() = (a: := valof y) in / 

The “value” (i.e. the val part in the above type) of such an expression is, in turn, of the type 

procedure = state — * val* —> ( val X state) 
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It can be applied in some state a to some tuple of values v, producing a result value and a new 
state. The environment at the point of its application does not affect its meaning. Thus, if the 
definition of / is evaluated (not applied) in an environment 77 with rfx — a x and 77 y = <*2, then 
the value of / is 

c = A <T. \{). {(<r a 2 ), <j[ot \ -► (<T a 2 )]) 

The variables x and y have been replaced by their bindings ai and a 2 , and this procedure will 
forever transfer the contents of the location a 2 to the location a\. A procedure value, such 
as c, is called a closure. The expression of which it is a value may have had free variables. 
But, they have all been eliminated before we obtain the value. The closure itself now does not 
“depend” on any variables. We can also conceive of languages (like Lisp) in which the meaning 
of the procedure depends on the environment at the point of application. Then, a procedure 
value should take as its parameter. Such a procedure value is not a closure. 

Another programming language feature concerned with closures is the declaration of mu- 
table variables in local contexts. To make this precise, let us add another construct to our 
example language: 

e ::= local x; e end 

Its semantics is given by 

[local x; e end^rr = 
let a = newloc <r 

- new location for x 

<j\ — extend a a . . 

- allocation of the location ' ’ 

r)i = 77(2 —►a] 

- local environment for e 

in [e] r/i 

This sequence of definitions arises so often in this paper that we introduce a new function alloc 
for it: 

alloc <t x = let a = newloc <r (2) 

<7 ! = extend <7 a 
Vo = V±[x^a] 
in (770, <T X ) 

Now, (1) can be simply rewritten as 

[local r; e end|77<7 = let (770, <Ti) = alloc a x ( 3 ) 

in [ej (77; 770) <7i 

Returning to our discussion of closures, suppose the expression e in such a context defines and 
returns a procedure, like in 


local x ; let /() = (x := valof y) in / end 

then the location assigned to x is built into /. Moreover, only / can access this location. The 
rest of the program can affect the value of the location only by calling /. It is often said that, 
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in such a situation, the location of x makes up the local state of /. More accurately, / has an 
exclusive “local window” on the global state (since it can access or modify the rest of the state 
as well). The rest of the program has neither access to, nor concerned with, the structure of 
this local window or the variables used for accessing it. 

We will show that objects in object oriented languages can be modeled by such closures 
with local windows to the state. Further, the model can be extended to cover the notion of 
classes and inheritance as well. 

We end this section with a table of the other semantic domains that we introduce in the 
subsequent sections. This should aid the reader as a quick reference. 


o G objectval 
p G menv 
p G method 
£ G classval 
ip G superclassval 


menv 

message — ► method 

state — ► val* — ► (val x state) 

state — ► ( menv x state) 

state — ► ( env x (menv — ► mem;) x state) 


3 ObjectTalk 

The simplest of our abstract languages is ObjectTalk. In this language, an object can be defined 
using the syntax 


e ::= obj = e u ...,m k (y k ) = e k } 

Here Xi,...,x n are the local variables of the object (also called instance variables), and 
m\, . . ,,m k are the “messages” (or operations) that the object responds to. The definition 
of a message is called its “method”. There is no notion of a class. However, methods can 
create objects each time they are called, so the effect of classes can still be achieved by objects. 
The syntax for sending messages to objects is 

e ::= e 0 .m(eZ) 

where e 0 is the receiver object, m is the message and eZ are the argument expressions. The 
following definition of a point object illustrates these constructs: 

P= obj (x, y){ 

put(a , b) = begin x := a; y := b end, , , 

dist() = sgrt(,$<jr(valof x) + «s<7r(valof p)), ' 

closer(q) — self ,dist() < q.distQ } 

This declares two local variables x and y for the coordinates of the point, and three messages. 
The message put takes two parameters for the x and y coordinates and sets the local variables 
to these coordinates. The message dist gives the distance of the point from the origin. Finally, 
closer takes another “point-like” object q as a parameter, and checks if this point is closer to 
origin than q . The special variable self denotes the very object that is being defined (p, in 
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this case). We could have used p in place of self. But, note that p is an external name being 
given to the obj expression. We would want to define objects without giving them names. The 
variable self is useful to refer to the object, in such contexts. 

What should objects denote? From the point of view of a user, an object simply responds 
to a set of messages. So, the meaning of an object should simply be an environment binding 
messages to their methods (message environments). The summand objectval of val can thus 
be defined by 

p £ objectval = menv = message — ► method 
p £ method = state — ► val* — ► ( val X state) 

The domain method is similar to the type of procedure values discussed in the last section. 
Here is our semantics for obj-expressions: 

|obj(x){m,-(p7) = €i}jT]<7 = 
let (t) 0 , <t\) = alloc <r x 

- value environment of the object 

P = P±[m»-+(A<r. A w. (r)]T) 0 \ijl->w)) cr)\ 

- message environment 
in (p,< Tx) 

The function alloc is as defined in (2) except that it is extended to deal with tuples of variables. 
Note that the message environment p produced as the value of the object expression is a closure, 
since the local environment tj 0 is completely absorbed in it. Thus the object has an exclusive 
window to the locations allocated in tj 0 . 

This semantics is not yet complete because we would like to have recursive references 
to an object’s messages in the methods defining those messages. This recursion is achieved 
indirectly by sending a message to the special variable self. For example, the object p defined 
in (4), invokes its own dist message in the method of closer using self. The use of self can be 
accommodated in our semantics as follows: 

Iobj(«){mi(y7) = e,}]]7?<7 = 
let (»7 0 , cti ) = alloc <7 x 
p = fix(Xp. p±[mi -♦ 

(A<7. Xw. lei] ( 77 ; Poiyi^w, self -»p])<r) 

]) 

in (p, <Ti) 

The only change is in the environment in which the method-expressions are interpreted. We 
bind the variable self to the message environment p that is being constructed for the object. 
But this makes the definition of p recursive, and we resolve it by introducing the fixed point 
operator fix. The use of fixed points to model references to self first appeared in [4]. 

The meaning of a message send is defined as follows: 

le 0 .m(e)jT]o- = let {p,<Ti) = le 0 \qcr 

- message environment of e a 

(v,<T 2 ) = Mwi (6) 

- values of arguments 
in p m a 2 v 
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Using the semantic definitions (5) and (6), the meaning of the point object p defined in (4) can 
be expressed as follows. Let a x and a y be two locations that can be allocated in the current 
state. 


p p = fix (A p. [ put — ► 

A<r. \(w a ,wi,). (wb, a[a x —>w a , a y 
dist — ► 


A<r. A(). (yV<**) 2 + (o-oiy) 2 , <r), 
closer — > 




\<r. A(pq). let = pdista () 

(V 2 ,cr 2 ) = p q distai () 
in (vi < v 2 , a 2 ) ]) 


Since this recursion converges finitely, we can simplify it to: 


Pp = [ put -+ 

A<7. A(t0 o ,t£7&). (T[a x -♦UJo, Oty -♦«;&]), 
dist — » 


A<t. A(). (^a^ + ^a,,) 2 , <t), 
closer — ► 

A<t. A(p,). let ri = ij(aa x ) 2 + (<r a y ) 2 
{v 2 ,a 2 ) = p q dista () 
in (vi < v 2 , <r 2 ) ] 


(7) 


Another idea we can think of is to let each object look at its own local state, without 
having a single global state that is modified by each method. Though appealing, this idea does 
not work. The reason is that methods can affect not only the object’s local state, but also 
the states of objects passed as arguments. So, it is not possible to define the denotation of a 
method as a function of the local state alone. Instead, our semantics passes the global state 
to every method, but permits it to directly affect the local state only. The value environment 
incorporated in a method (tj 0 ) only gives it a “window” on the local state. 


4 Class Talk 

In this language, we introduce classes without inheritance. The syntax is similar to that of 
objects: 

e ::= class ( xi,...,x n ) {mi(yT) = ei, . . .,m k (yk) = «*} 

Instance objects of classes are created by the expression 

e ::= new e c 

Now, we cam define a generic point class instead of a specific point as in (4): 
point = class (*,y){ 

put(a,b) = begin x := a; y := b end, . > 

dist( ) = sgrt(s?r(valof x) + s9r(valof y)), 
closer(q) = self. dist() < q.dist() } 
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Every evaluation of new point yields a new instance of point. 

The semantics of classes should naturally satisfy the property 

[new class(zi,...,z n ){m 1 (yT) = e lt . . ., m k (yk) = e fc}] ^ 

= [obj(*i, . . . , ®„){m 1 (yr) = ei, . . . , m k (yk) = e fe }j 1 

since instantiating a class expression to get an object is the same as directly using an obj- 
expression. So, the class construct provides an abstraction which can then be invoked to obtain 
an objectval. The simplest such abstraction is the domain 

£ 6 classval = state — *• ( menv x state) 

and we add it as a new summand to the val domain. A classval does not give a message 
environment in itself, but yields one when “instantiated” in a state. This in turn is accomplished 
by new. 

[class(i){mi(yi) = e<}]]» ?<r = 

(Act', let (ry 0 , o[) = alloc o' x 
p = fix{\p. pi [m t - — ► 

(\<r. Xw.leij(T];Tj 0 [yi-*w, self ->p])cr) (10) 

]) 

in (p, <t[), 

°) 

Note that a class-expression does not change the state. It merely denotes a template for creating 
new objects. (Thus, we could have interpreted class expressions without reference to a state. 
The reason for not doing so is pedagogical. It allows us to use a single semantic function for 
all syntactic constructs). The meaning of new is to invoke the template: 

[new e^pcr = let ((, a x ) = le^pcr 
in £<ri 

Classes do not add any expressive power to ObjectTalk owing to the equivalence (9). In 
fact, the effect of classes can be achieved in ObjectTalk by the following translation 

class(x){M} = obj(){neu;() = obj(z){M}} 
new c = c.new() 

However, ClassTalk has an advantage from a software engineering perspective. There are good 
reasons to disallow free variables denoting objects in obj or class expressions. That way, we can 
treat every object as a self contained unit. In fact, in Smalltalk-80 no free object references are 
allowed in class descriptions. But, we do want class descriptions to refer to other classes. This 
is like importation of modules. The above simulation of classes in terms of objects does not 
allow such preferential treatment to free class references. So, even without inheritance, classes 
are useful. 

The semantics we are presenting does not model the restriction that class expressions may 
not have free references to objects. But, it would straightforward to model the restriction by 
splitting the environment into a class environment and an object environment. 
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5 Inherit Talk 


In this language, we introduce a simple form of class inheritance. A subclass of another class 
can be expressed by the construct: 

e ::= subclass e c (zj, . . x n ) (m^yf) = e x , . . ., m k {yk) = e k } 

An instance of such a subclass would have all the variables £i, 

. . . , 

x n as well as the instance variables of the superclass e c . Similarly, it would accept all the 
messages mi, . . ., m* as well as the messages specified in e c . There is also a notion of over- 
riding. That is, if a message m is specified in both the superclass and the subclass, then o.m 
is interpreted as the method defined in the subclass. However, the behavior of instances of e c 
are (reasonably) not modified by the subclass specification. This is similar to the overriding 
caused by statically nested scopes. In fact, our semantics of inheritance in InheritTalk closely 
follows that of nested scopes: 

[subclass e c («){mj(yi) = ei}\qo = 
let (( c ,o i) = {e^rjo 
in (A o'. let (p c ,<7i) = 

(tj 0 , o' 2 ) = alloc o[ x 
P = fix(Xp. p c {rnx-> 

(A<r. Xw. [e<l (77; Vo[yi~*w, self->p]) a) 

]) 

in (p,<r' 2 ), 

) 

When instantiated in a state o', the classval of the subclass first instantiates the classval, f , 
of the superclass. This yields a message environment p e . The subclass then allocates storage 
for the additional instance variables *, and yields the message environment p. This message 
environment is obtained by updating the environment p c produced by the superclass with new 
message bindings for m,. The essential difference between this and the semantics of the class 
construct (10) is in the use of p e instead of px in constructing p. The class inheritance of 
Simula [7] and C++ [18] work in this fashion (when virtual functions are not used). 

6 SmallTalk 

Note that, in InheritTalk, the variable self means different message environments in a superclass 
and its subclass. It can be justifiably argued that self should denote the message environment 
of the receiver object, and therefore should have the same meaning in both classes. Consider, 
for example, the following subclass manpoint (for Manhattan point from [10]) of the point 
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class: 


point = class (a:, y){ 

put(a,b) = begin * := a; y := b end, 

distQ = sqrt(sqr(va\of x ) + s<?r(valof y)), 
closer(p) = self.dis<() < p.dist() } 

manpoint = subclass point (){ 
dist( ) = (valof x) + (valof y)} 

manpoint inherits put and closer messages from the point class, but uses a different notion of 
“distance from origin” (the sum of the x and y coordinates). We want to be able to compare 
manpoints using the closer operation inherited from the point class. But, such a use of the 
closer operation should use the dist method defined in manpoint rather than that defined in 
point. Note that InheritTalk does not achieve this kind of inheritance. What is inherited by 
manpoint in InheritTalk is a fixed behavior of an object as a point , as in (7). The recursion over 
self is already resolved in such behavior, and closer can only compare the Euclidean distance. 
But, inheritance in Smalltalk-80 does not make such early commitment to the meaning of 
self. Any instance of manpoint consistently uses the new method for dist defined in the subclass 
definition. Similar inheritance can be achieved in C++ using “virtual” functions. We call this 
form of inheritance dynamic inheritance (and, by contrast, the inheritance of InheritTalk static 
inheritance) since the meaning of self is not determined statically by the class expression in 
which at appears, but dynamically when the class is instantiated. 

This form of inheritance poses an interesting semantic issue. If manpoint inherits the 
“behavior” of closer from the point class, then closer cannot behave differently in the instances 
of point and the instances of manpoint. So, what is inherited from point is the “behavior of 
closer parameterized by the behavior of self”. This means that the semantic description of a 
class-expression cannot directly bind self. Its binding would be known only when the class is 
instantiated by new. So, the meanings of class-expressions would now involve transformation 
functionals of the kind 

r 6 menv -* menv 

We can think of r as accepting the menv of self as a parameter, and producing a new menv 
for self. Such functionals were also involved in the semantics of ClassTalk and InheritTalk; but 
we could immediately eliminate them as we were only interested in the fixed points of such 
functionals. This we cannot do for SmallTalk. 

Another semantic issue of Smalltalk-80 that we would like to model is that the instance 
variables specified in a class c are visible to its subclasses. For instance, manpoint references 
the instance variables * and y specified in point. This means that it is not possible to hide the 
local environment in a class definition. These two issues motivate us to replace the subdomain 
classval of val by 

€ super classval — state — + ( env X (menv — ► menv) X state) 

The superclassval of a class is its meaning as seen by a subclass of it. But, to instantiate a class 
using new, we need its classval. The following mapping close shows that the superclassval 
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has all the information needed to determine the classval : 

close : superclassval — ► classval 

close V> = A a. let (77, r, erf) = ipcr 
in {fix t, <7i) 

When instantiated in a state a, a superclassval produces a triple {77, r, <7i). If the instantiation 
is done using new, then the environment 77 is ignored, and the fixed point of r is produced 
as the object. If the instantiation is from a subclass, then the subclass can extend 77 with 
additional variables and r with additional messages, to produce another such triple. 

The syntax of SmallTalk is the same as that of InheritTalk. Only the semantics is different. 

Jclass(®){mj(y7) = e^pcr = 

(Act', let {tj 0 , <r[) = alloc <r' x 

v' = m Vo 

r = Ap. pj.[r 7 ij — ► 

(Act. Au>. [e<J (7?'[i/i-> w, self -»p])<r) 

] ■ 

in (t 7*,r,<rJ), 

The major difference between this and the semantics of class-expressions in Class Talk is that 
instead of producing a message environment as a fixed point of a transformation functioned (r), 
it produces the functioned itself. 

The meaning of a subclass of e c is as follows. When instantiated in a state, it first instanti- 
ates e c , extends the local environment created by e c , and then extends the menv transformation 
functional determined by e c . 

[subclass e c (x){mi(yi) = e^pcr = 
let {tf>, <Ti) = le c }rjcr 
in (A a', let {r) c ,r c ,(r[) = xfar' 

(Vo,^) = alloc <j[ x 
V' = V, Vc\ Vo 
t = A p. r c p[mi —* 

(A a. \w. self-^p]) <t) 

] 

in (t ?', r,<r£), 

^1) 

The significant part of this semantics is the definition of r. Given a binding p of self, rp first finds 
r c p (the menv determined by the superclass e c ) and then extends it with new message bindings. 
This technical meaning of Smalltalk -80 style inheritance was independently discovered by 
Cook [6]. 

Smalltalk -80 also has a special variable super which, appearing inside a method expres- 
sion, denotes the receiver object viewed as an instance of the superclass. This can be modeled 
by modifying the environment used for method expressions e, to be 

v'[yi~> w, self -► p, super ->• T c p] 
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The semantics of new is to close the superclassval to a classval and instantiate it in the 
current state: 

[new ejijo- = let (tl>,<r{) = le c Jrjo 
in close tfj <T\ 

Let us use the point and manpoint classes to illustrate these semantic definitions. To make 
the meanings intuitive, we use an informal description. The menv transformation functionals 
(for an object with local environment p 0 ) are 

TpointiVo] = A p. [put -* set T) 0 x and rj 0 y, 

dist —v Euclidean distance, 

closer -* compare pdist and argument’s dist 

} 

TmanpointiVo] = A p. [put -+ set Tj 0 x and T) 0 y, 

dist —> Manhattan distance, 

closer —> compare pdist and argument’s dist 

] 

Notice that only the binding of dist is changed. When we close the super classvals for instan- 
tiation, we get the respective menus as fixed points: 

/Vintfro] = \put -► set p 0 x and p 0 y, 

dist —y Euclidean distance, 

closer —y compare Euclidean distance and argument’s 

dist 

] 

PmanpointiVo] = [put -+ set r) 0 x and p 0 y, 

dist —y Manhattan distance, 

closer —y compare Manhattan distance 

and argument’s dist 


This illustrates that Smalltalk style inheritance occurs at the superclassval level rather 
than at the classval level. This fact can be used for reasoning about object oriented programs 
as follows. When a class (or a subclass) defined, we cannot make any assumptions about 
the behavior of self except that it looks something like the menv being defined. When a 
class is instantiated, the instance object fixes the meaning of self and its behavior becomes 
determinate. Another way to think about programs is by giving two meanings to each class, in 
terms of superclassvals and classvals. The superclassval meaning is as just mentioned. The 
classval meaning assumes that self has the same behavior as the menv being defined. In this 
view, we have to remember that what is inherited is the superclassval and what is instantiated 
is the classval. 

The fixed point involved in the above semantic definition merely models the recursion in- 
volved in references to self in class definitions. There may be another other kind of recursion 
involved in an object-oriented program. This involves class references rather them object ref- 
erences: the description of a class may create its own instances. This can be mutual recursion 
as well, with two classes creating each other’s instances. All such recursions would be built 
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into the environment rj which we are assuming to be available in all the semantic definitions so 
far. To illustrate this, we will add yet another construct to SmallTalk. This will also facilitate 
comparison with the semantics of Kamin who uses a similar construct: 

e ::= hierarchy X\ = ei, . . . , x n = e n in e 

We intend that a construct like this be used at the top level of a program. All the expressions 
ei axe restricted to be class-expressions and the only free variables in them are the class names 
xi,...,x n . These variables can then be used in the body expression e. The semantics of this 
is fairly conventional: 


[[hierarchy x\ = ei, = e n in c] = 

let <fi = A77. T) X [xi -* fst (|ei]|t 7 < 7 j.)] 

77 = fix <j> 
in Ie]]77<7x 

We call the fixed point involved in this construction an environmental fixed point to distinguish 
it from the fixed point over self which we have seen before. 

7 Relation to Kamin’s Semantics 

As mentioned in the introduction, Kamin [10] used different framework for describing the 
denotational semantics of Smalltalk- 80 . Our work grew out of the contention that this 
semantic description was not sufficiently abstract. In this section, we make this observation 
concrete by comparing the two semantic descriptions. First of all, let us reexpress Kamin’s 
semantics in our notation. The semantic domains are given below. We subscript the domains 
involved in Kamin’s semantics by K. References to our semantic domains in this section are 
subscripted by A (for “Abstract”) to distinguish them from the former. 


V, w 

€ 

valjc 



basicval + loc + objectvalK + classvalK 

V 

e 

envK 

= 

variable — ► valjc 

<T 

€ 

stateK 

= 

loc — ► valic 

p 

6 

menvjc 

= 

message — ► methodic 

p 

6 

methodic 

= 

stateK —* objectvalK — ► val* K —*■ 





( voIk x stateK ) 

0 

€ 

objectvalic 

= 

envK x classname 

c 

€ 

classname 



t 

€ 

classvalic 

= 

variable * X menvK 


13 



The domains methodic, objectvalic and classvalic differ from ours. The meaning of a class 
expression is given by: 

fdass(*){mi(jjT) = e»}]]r?<r = 

let p = p_L[rrii-> Acr. A o r . Aw. let (p r ,c r ) = o r 

in -*• to, seif -*■ o r ] )<r] 

in ((x,p),<r) 

Let us cut through the formalism to indicate what is going on here. 

1. The denotations of objects contain a local environment and a classname. The latter in 
turn determines a message environment. The local environment is not hidden as in our 
semantics. Moreover, this description involves unconventional use of the syntactic domain 
classname. Traditionally, denotational descriptions only use names as input domains of 
environments. But, here classname is being used in the semantic domain objectvalic. 
As we will shortly see, this indirect referencing of classes from objectvals is critical to 
Kamin’s semantic description. 

2. The denotations of classes, likewise, contain the local instance variable names in addition 
to the message environment. Message environments are associated with classes rather 
than with objects. 

3. The denotations of methods take an implicit argument denoting the receiver object o r , in 
addition to the arguments supplied in a message send. Since the denotations of methods 
are defined in the context of their classes, the receiver of the message is completely 
unknown at this point. So, it is necessary to make a method a function of the receiver. 
References to self in a method definition are interpreted as references to this implicit 
argument (Cf. the environment used for inbracketse , in the semantic definition). 

4. There is a kind of dynamic binding involved in the interpretation of method expressions. 
The environment rj r is obtained dynamically as part of the parameter o r to the method, 
but is used for binding the free variables in e. 

The semantics of instantiation and message send clarify these points. (We first define an 
auxiliary function to look up the menv of a class in an environment): 

lookup c rj = let (x, p) = p c in p 
[[new c\ricr = let ( x , p) — pc 

{r)o,<ri) — alloc <r x 
in ((%, c),< 7i) 

| e 0 .m(e)jr]<r = let ((t7 0 , c„), cri) = fej^cr 

P = lookup Co 7] 

(u,<7 2 ) = 

in pm o 2 ( t\ 0 , c 0 ) v 

Unlike our semantics of ClassTalk or SmallTalk, there is not yet any recursion in this semantic 
description. There seem to be two reasons for this. Firstly, the methods are defined as functions 
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of the receiver objects. So, there is a delayed self- reference here. Secondly, the use of classnames 
also involves a delayed self-reference. If, for instance, we directly use the environment p instead 
of classname c in objectval , then the semantics of message send would involve a self-application 
of p: 

pm<T 2 (r ] 0 , p) v 

This may then introduce implicit recursion. All these delayed recursions are pushed into the 
environment 77. Consider again, the point class we have mentioned before: 

point — class (x, y){ put(a, b ) = begin x := a; y := b end, 

dist() = s^rt(sgr(valof a:) + sqr(v alof y)), 
closer (p) = self.dist() < p.dist{) } 

The menv component of this class-expression can only be determined in an environment 77 as 
follows: 

PpointW = [ PUt -* 

Act. A(t7 r ,c T ). \{w a ,w b ). ( w b , <r[q T x ->w a , ri r y->w h }), 
dist — 

\<T. \{T) r ,c T ). A(). (v/<7(i7 r ®) 2 + <r(77 P y) 2 , <r), 
closer — ► 

A< 7 . \(T) r ,C r ). \{{TJ p ,Cp)). 

let p r = lookup c r 77 
p p = /ooA:tip c p tj 

{vi,(Ti) = p T dist a (77,, Cr) () 

(U2,<T 2 ) = Ppdistcrx (rip,c p ) () 

in (t7i < 172, ^ 2 ) ] 

The environment 77 is needed to look up the menv components of the classes c T and c p . 

The delayed recursions are then captured by the environmental fixed point in the semantics 
of the hierarchy construct. 


[hierarchy ci = ei, , c* = e* in ej = 

let <t> = A77. 77x [ci fst ( [ei]]77<T X )] 

7} — fix <f> 
in [ej 77 a L 

In [10], the functional <f> and the environment 77 are given by two separate semantic functions 
D and C of the hierarchy. When the definition of the class point is given in such a hierarchy 
construct, the fixed point construction allows us to consider every possibility for the classes c r 
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and c p . If point is the only class defined, then we have 

Ppoint = [ put — ► 

A<7. A{r; r , Cr). X(w a ,w b ). ( w b , <T[77 r i^u; a , 77 r y-+ti; 6 ]), 

dist — ► 

A<7. \(Vr,Cr). A(). (v/<T(77 r x) 2 +<r(7; r y) 2 , <t), 
closer — > 

\(T. A(r/ r , c r ). A((jjp, Cp)). 
c r = point A c p = point — ► 

let Vi = i /<r(r? r x) 2 + <y(r/ry) 2 
u 2 = yj°\ripx) 2 + ^[Vpy) 2 
in (v x < u 2 , <t); 

-L] 

If the hierarchy has two other classes, say fine and manpoint both of which have a message dist, 
then the binding of closer in Ppoint would define separate results for each of the 9 combinations 
of c r and c p . If manpoint is a subclass of point but line is unrelated, then it is certainly 
meaningful to handle the case c r = manpoint because the receiver object may well be an 
instance of manpoint ; but, the case c r = line would never arise. So, passing the receiver object 
as an implicit argument to a method is somewhat an overkill. 

The set of possibilities for the menus of both the implicit and explicit arguments in this 
semantics is finite (the set of classes defined in the hierarchy construct). On the other hand, 
in our semantics for SmallTalk, there is only a single possibility for the implicit argument 
(determined at the time of instantiation) and the set of possibilities for the explicit arguments 
is unrestricted . 

The semantics of inheritance in this framework is quite straightforward: 

[[subclass c (z){m(y) = e)\rjo = 
let ( z c ,p c ) = T)c 

p = p c [m— > A<t. A o t , Xw. let (p r , c r ) = o r 

in -*•«>, self — +o r ])er] 

in «x-x c , p), <t) 

There is no need for superclassval because the message environment of self is obtained directly 
from the implicit argument denoting the receiver. Or, viewed a little differently, a classval 
in this framework is indeed like our superclassval because each method takes a parameter 
denoting self. 

In summary, the denotations in Kamin’s semantic description contain strictly more infor- 
mation than our denotations and hence are less abstract. 

7.1 Classes as types 

We should not, however, dismiss Kamin’s framework as being just too low-level. It provides 
an important alternative view point of object oriented programming. 

In our entirement treatment of object oriented languages, we have viewed classes merely as 
abstractions (procedures) used for generating instance objects. But, classes are also meant to 
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be types. That is what the very term “class” signifies. Classes are not structural types in the 
sense of [3, 13, 14], but behavioral types or abstract types. So, a semantics of classes should also 
throw some light on how a class may be viewed as a collection of objects and what is common 
to all such objects. 

At the progr ammi ng level (as opposed to the specification level), an abstract type is de- 
noted by a scheme of representation and a definition of the operations on the representation. 
Kamin’s classvals as pairs (x, p ) of instance variables and message environments precisely fit 
this description. What is common to all the instances of a class is that they till have the in- 
stance variables x and share the behavior p. Thus, Kamin’s objects can merely reference their 
classes to determine the behvior. It is hard to state what is common among our objects with 
regard to their classes, since each object has its “own” behavior unrelated to other objects. 

Kamin’s treatment of object-oriented languages is, in fact, remarkably close to conven- 
tional abstract data type languages like Alphard [16] and CLU [8]. The operations (message 
environments) in these languages are associated with abstract types (classes) rather than with 
individual data objects. Alphard, in fact, treats the first argument of an operation as a special 
one for obtaining the binding of the operation name, which brings it very close to modem ob- 
ject oriented languages. Kamin’s methods similarly use their first argument (implicit argument 
denoting the receiver object) as a special one for obtaining the message environment. What is 
different in Alphard is that the association between objects and types is determined statically. 
If we extend it to allow dynamic association, we would obtain a framework much like that used 
in Kamin’s semantics of Smalltalk-80. 

These observations point to new directions for future investigation. Kamin’s treatment is 
able to depict classes as types, but, on the negative side, makes the internal representations of 
objects visible in their denotations. Our treatment hides the internal representations, but loses 
the ability to capture the commonality of the instances of a class. Is there a way to semantically 
hide the representations, without losing the commonality of instances? The answer to this may 
lie in semantic devices like existential types [5, 15] and dependent types [2, 12]. 

There is another question we may ask in this connection. Kamin’s semantic treatment 
shows that if we extend an abstract data type language like Alphard with dynamic typing and 
inheritance, we naturally obtain dynamic inheritance of the kind in our SmallTalk. Simula 
and C++, on the other hand, retain static typing and the inheritance obtained in them is 
static inheritance of the kind in our InheritTalk. Is there a relationship betwen static typing 
and static inheritance, on the one hand, and dynamic typing and dynamic inheritance, on the 
other? 

8 Conclusion 

We have described the semantics of object-oriented languages by treating objects as closures. 
Specifically, we interpret an object as a message environment (binding messages to methods) 
with a hidden local environment (binding instance variables to values or locations). We have 
shown that this framework can be extended to give full descriptions of classes, instantiation, 
and inheritance in the style of Simula as well as Smalltalk-80. 

We have also compared our approach to the semantics of Smalltalk-80 given by Kamin 
in a recent paper [10]. Kamin interprets objects as pairs with local environments and class 
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references. Local environments are not hidden as in our semantics, and class references, rather 
than classes, are used in denotations. We have discussed the various implications of these 
differences. 

Our semantics and Kamin’s semantics may be seen as two different views of object-oriented 
programming. We associate operations with objects, and treat classes as abstractions (func- 
tions) used to generate such objects. Kamin associates operations with classes, and treats 
objects as data records with associated classes. The latter view is closer to languages based 
abstract data types, whereas ours is closer to conventional functional programming concepts. 
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